Global Protect
User Connects to Gateway When a user connects to through Global Protect for the first time, they'll usually insert the ip address or the FQDN in their browser. Once they do this, a packet is sent with a source of the user at a random port a destination of the Global Protect Gateway (IP/FQDN) at port 443. The gateway, because it's listening on port 443 for this traffic, receives the packet with the destination port of the packet at 443 and starts the SSL handshake. You must make sure the PA Gateway is 'listening' on port 443 for this traffic, otherwise you'll get nothing: admin@PA-9000> debug ssl-vpn socket Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:20077 0.0.0.0:* LISTEN 3926/appweb3 tcp 0 0 0.0.0.0:20088 0.0.0.0:* LISTEN 3926/appweb3 tcp 0 0 127.0.0.1:49968 127.0.0.1:20077 TIME_WAIT - You can also make sure that when that packet is first received, the SSL service is running on the Palo: admin@PA-9000> show system software status | match ssl Process sslmgr running (pid: 2534) Process sslvpn running (pid: 3926) Once the client connects to the gateway via SSL the SSL handshake will take place as shown below. In phase 2, the server hands over it's certificate to the client and the client validates the certificate. This is where we'll need to be sure about our deployment type and information concerning certificates. We normally would generate a self-signed certificate on the Palo as a root CA for the global protect clients. Global Protect Certificates Certificates are created and referenced in the gateway and portal configurations shown below: Generate the Certificate to be Used for Global Protect The FQDN is important if the clients will be using this to connect to the gateway. It needs to be the same name. This certificate will be inserted into the Portal and Gateway configurations show below: Portal Configurations Gateway Configurations Host Download and Installation of Global Protect Agent After the certificate is given to the client and the client accepts the certificate, the landing/splash page shows an option to download the client agent for installation. This agent is referencing a file on the firewall that was previously downloaded. Below there shows two versions as downloaded. If the version is downloaded and not active, the client will NOT receive the packet and the entire operation is broken so be sure to active the version that's downloaded. Once the file is downloaded, install the program. The program will contain the client certificate so that the firewall can authenticate the client. Authenticate the User Once the application is installed on the client machine they'll have to insert their credentials. To authenticate the user, the firewall will have to reference a list of usernames and passwords. Create a User Optionally Create a User Group Attach Users to Authentication Profile Now that we have created a user and associated them with an authentication profile, we'll have to tell the portal and gateway to reference this list for user authentication. User/User Group If you have more than user group, you can choose who to authenticate based off the authentication profile. The portal allows for the option to authenticate in many ways but if you don't want all of the users to connect in the same way, you can set up user/user groups. In the example below, I want the first group to connect with user-login and use the SSO option but the second group I want them to connect on-demand without the SSO option. When to Authenticate the User The user needs to authenticate when outside the network. When the user is inside the network there is no need to authenticate. The option below allows you to insert an internal host name and it's corresponding IP address. If the machine cannot resolve the hostname to the correct IP, the computer assumes that the internal DNS server is not within reach and will attempt to authentication by connecting to a gateway. If the hostname CAN be resolved to the IP address, the computer will assume that it is located on the internal network because the internal DNS resolution succeeded. Define Where the User Can Go Once the user is authenticated, they'll have access to the network. You can add service routes to lock down or provide more access to the network as well. First, list the gateways the user can access. You'll define this in the portal settings. Below the gateway with IP of 192.168.1.1 is entered as the gateway. It's usually the gateway on the device itself, just referenced again here for the clients. If you have multiple gateways, you need a license to go along with it. When is more than one, you can select the 'Manual' button to allow the client to manually select the gateway and you can also assign a gateway priority of lowest, low, medium, high, highest or manual only. Manual only locks the priority down to client selection. Tunnel Mode When using tunnel mode, you can select the Access/Service routes and DHCP pools. Below the client will receive an IP address from the pool 10.0.1.1 - 10.0.1.254 and when they do, they'll have access to 192.168.1.0/24 and 172.16.1.0/24. These routes will be installed on the client PC upon authentication.